1. Field of the Invention
This invention relates to the delivery of television programming and more specifically to the “Just In Time” delivery of essential data elements to facilitate the decryption and decoding of programming at reduced bit rates.
2. Description of the Related Art
Television programs are distributed to viewers by a variety of broadcasting methods including traditional analog broadcast television (National Television Systems Committee or “NTSC” standard), the digital broadcast television “Advanced Television Systems Committee or “ATSC” standard), cable television (both analog and digital), and satellite broadcasting (both analog and digital. These methods allow audio and video streams for television programming to be multiplexed into a transport stream and transmitted over a common transmission medium.
As shown in FIG. 1, the “headend” 10 of a satellite broadcast system 12 includes among other functions a traffic & scheduling center 14, a satellite broadcast center 16 and a conditional access management center (CAMC) 18. The broadcast center encodes, encrypts and multiplexes programming content, either stored or from live feeds 20, into a packetized transport stream 22 that is uplinked to satellites 24 via an antenna 26. The center inserts essential data elements (EDEs) into the transport stream that are required for decryption and proper display by customers. Entitlement Control Message (ECM) packets determine which customers are authorized to decrypt specified programming. A Program Clock Reference (PCR) and Program Time Stamp (PTS) are required for synchronous playback of the video, audio and other streams. A Decoder Time Stamp (DTS) may also be included.
To view a television program on a TV 28, a subscriber may have to subscribe to a service package offered by a pay-TV service/transmission provider such as a direct broadcast satellite (DBS) operator (e.g., DIRECTV) or a cable company. Such a pay-TV service provider may require a subscriber to utilize an integrated receiver decoder (IRD) 30 that enables the descrambling or decryption of the transmission downloaded from an antenna 32. The IRD may be configured to allow the viewing of one or more particular channels, programs, etc. based on a subscriber's payment or subscription. Accordingly, when a subscriber subscribes to a service package, the pay-TV service provider supplies the decryption information to the set-top box via the ECMs in the transport stream to allow the subscriber to view the transmission in the selected package. The IRD locks its internal clock to the encoder clock provided by the PCR. This enables synchronous playback of multiple elements such as video and audio. The IRD uses the PTS contained in the PES packet header to determine what time, relative to the reference clock, to actually play out the element. The DTS (if included) suggests a time when the decoder should initiate decoding.
As shown in FIG. 2, a typical MPEG packet 40 in the transport stream 22 is of a fixed length, 188 bytes for DVB, of which the first 4 bytes contain header information 42 and the remainder is payload 44. The header includes among other things a sync byte “0x47”, a payload_unit_start flag, the program ID (PID), an adaptation_field_control flag and two transport_scrambling_control bits, one bit marks the key sense and the other marks whether the packet is encrypted or not. The PID is a number. The program guide defines what (audio, video, ECMs, program guide, program list, etc.) is on a given PID. If the adaptation_field_control flags are set, the packet contains an adaptation field and may contain a PCR for the associated data stream. Traditionally, the PCR appears on the video stream but may appear on both audio and video or on a separate PID. If the payload_unit_start flag is high, the packet contains a PES header, which may contain a PTS (or DTS). For complete description of the packet structure and transport stream see ISO/IEC 13818-1.
As shown in FIG. 3, to create the transport stream 22, each Encoder/Program Mux 60 encodes a video stream and one or more audio streams for a different program into a packetized program stream 62 assigning each audio and video stream a unique PID. The encoder also inserts a PCR at regular intervals (30× per second) in at least the program stream and a PTS time stamp for every frame (also 30× per second but synced to the frame) in both the video and audio streams (at each packet of) as specified by international ISO/IEC 13818-1. The PCR is traditionally sent with the video stream but may be sent with the audio or assigned its own PID and sent as a separate packet. The PCR and PTS time stamps represent about 4800 bits per second in overhead bits. A Program Guide Generator 64 generates packets that include updated program guide information. A PID list including PIDs for video, audio, and ECM that together make up a program is sent as part of the program guide.
An ECM generator 66 generates an ECM packet with its own PID that includes a “secret message” that an IRD can decode to derive the embedded encryption key needed to decrypt the associated audio/video or data streams. The encryption key is typically updated every 8 seconds by a codeword generator 68 and transmitted at more frequent regular intervals, say 10× a second, by the generator to allow the IRD to start decoding when a customer changes channels. Typical ECM packets represent about 16 kilobits per sec in overhead bits.
A Statistical Mux 70 multiplexes the program streams together with the program guide and ECM packets into the transport stream 22. The Mux may also control the bit allocation between the program encoders to maintain constant quality of the video across programs. The Mux may also vary the split, e.g. 80/20, between video and fixed rate streams (audio, program guide, ECM). The Mux also inserts NULL packets as placeholders for time-insensitive data transmission (program guide, various data, etc.) and as fillers when there isn't enough encoded data to fill the transport stream. The Mux adjusts the pool of NULL packets to keep the output NULL packet rate very near zero. An encryption box 72 encrypts the “payload” in each packet in accordance with the crypto codeword appropriate to the associated ECM. DES and AES are standard encryption methods. The fully multiplexed encrypted transport stream has a rate of 10-20 Megabits per second.
In current MPEG-2 based systems, the amount of overhead associated with essential data elements consumes only a small portion of the available bit rate. However, as the newly adopted ISO/IEC 14496-10 compression standard referred to synonymously as JVT, AVC, H.264 or MPEG-4 Part 10 is integrated into delivery systems the amount of overhead consumed by the EDEs on a percentage basis will increase. In general JVT offers substantially greater compression than MPEG-2 and in simple scenes such as a “talking head” allows bit rates as lows as about 1 kilobit per second (or one packet per second). Clearly, at these low rates, the overhead associated with transmitting the EDEs, particularly the ECMs, becomes very high.
The problem is exacerbated by the increasing complexity, and thus length, of the ECMs. This is especially true for satellite broadcasters who broadcast to, for example, the entire United States and need a sophisticated ECM to transmit specific “black out” information. Although this enhances the capabilities of the system, it also may increase the ECM length several fold. ECM length also continues to increase as the sophistication of pirates' increases.
One solution is to simply reduce the frequency at which the ECM, PCR and PTS are regularly inserted into the stream to maintain a desired percentage overhead. Unfortunately since the delivery of the EDEs is needed to enable a customer's IRD to decode and display the programming, this approach would lead to unacceptably long delays when channel surfing. Another obvious solution is to reduce the complexity of the ECM message, but this makes the “pirates” job much easier. One solution impacts customer satisfaction, the other impacts revenue.